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EXECUTIVE  SUMMARY 


The  need  for  efficient  storage  and  processing  of  very  large 
databases  to  support  decision-making  and  the  advances  in  computer 
technology  have  made  research  and  development  of  database  management 
systems  with  specialized  architectures  a  very  attractive  and  important 
area.  The  INFOPLEX  database  computer  proposed  by  Madnick  applies  the 
theory  of  hierarchical  decomposition  to  obtain  a  specialized  architecture 
for  database  management  systems  with  substantial  improvement  in 
performance  over  conventional  architectures. 

A  key  question  in  the  architectural  design  of  the  INFOPLEX  data 
storage  hierarchy  is  how  to  reduce  erroneous  design  decisions  by 
eliminating  potential  system  bottlenecks  and  assessing  system  response 
time  as  well  as  system  throughput  so  that  performance  requirements 
can  be  met.  Simulation  and  analytic  modeling  are  two  primary  approaches 
to  answer  the  question.  Simulation,  although  more  accurate  than  the 
analytic  approach,  is  not  cost  effective.  Preliminary  analytic 
results  in  this  report  indicate  that  analytic  modeling  techniques  are 
applicable  as  well  as  cost  effective  to  the  performance  evaluation  of  the 
INFOPLEX  data  storage  hierarchy.  The  results  obtained  from  operational 
analysis  and  those  from  RESQ  are  identical;  when  comparing  with  simulation, 
the  results  are  comparable  to  within  a  factor  of  two.  This  indicates  that 
analytic  techniques  are  consistent  but  too  gross  to  incorporate  some  primary 
effects.  A  closer  examination  reveals  that  overhead  due  to  unbalanced  flow 
is  not  included.  Future  reports  will  address  this  issue. 
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1  Introduction 


1.1  The  IMFOPLEX  Data  Base  Computer 


The  need  for  efficient  storage  and  processing  of  very  large 
databases  to  support  decision-making  coupled  with  advances  in 
computer  hardware  and  software  technology  have  made  research  and 
development  of  specialized  architectures  for  database  management  a 
very  attractive  and  important  area. 


Die  INPOPLEX  data  base  computer  proposed  by  Madnick  applies  the 
theory  of  hierarchical  decomposition  to  obtain  a  specialized 
architecture  for  database  management  with  substantial  improvement  in 
performance  and  reliability  over  conventional  architectures.  The 
storage  subsystem  of  INPOPLEX  is  realized  using  a  data  storage 
hierarchy.  A  data  storage  hierarchy  is  a  storage  subsystem  designed 
specifically  for  managing  the  storage  and  retrieval  of  very  large 
databases  using  storage  devices  with  different  cost/performance 
characteristics  arranged  in  a  hierarchy.  It  makes  use  of  locality  of 
data  reference  to  realize  a  low  cost  storage  subsystem  with  very 
large  capacity  and  small  access  time.  (Lam79) 
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1.2  Structure  and  Algorithms  of  DSH-11 

V. 

A  design  of  the  general  structure  of  the  INFOPLEX  Data  Storage 
hierarchy  is  described  in  (Lam  and  Madnick, 1979b) .  A  simplified 
design  of  the  INFOPLEX  Data  Storage  hierarchy,  referred  to  as  DSH-11, 
is  described  in  (Lam  and  Madnick, 1979c) .  Detailed  protocols  for 
supporting  the  read-through  and  store- behind  operations  in  DSH-11  are 
also  presented  in  (Lam  and  Madnick, 1979c) .  The  DSH-11  structure  and 
the  DSH-11  algorithms  are  briefly  reviewed  here  : 

The  DSH-11  structure  is  illustrated  in  Figure  1.1.  The  highest 
performance  storage  level,  L(l),  consists  of  the  data  caches.  Each 
data  cache  corresponds  to  a  DSH-11  memory  port  that  connects  to  a 

*  processor.  All  the  data  caches  share  a  local  bus,  LBUS1.  There  is  a 

storage  level  controller,  Kl,  that  serves  as  the  communication 
gateway  between  L(l)  and  lower  storage  lebvels. 

A  typical  storage  level,  L(i),  for  i  greater  than  1,  consists  of 
a  storage  level  controller,  Ki,  a  memory  request  processor,  Ri ,  and  a 
number  of  storage  device  modules,  Dil,  ..,  Dim.  All  these  modules 
share  a  local  bus,  LBUSi.  Ki  is  the  communication  gateway  between 
L(i)  and  other  storage  levels.  Ri  maintains  a  directory  of  all  the 
data  in  L(i).  Dij  performs  the  actual  storage  and  retrieval  of  data. 

4 

The  global  bus,  GBUS,  connects  all  the  storage  level  controllers 

« 

of  the  storage  levels.  All  commimicatio  s  among  storage  levels  make 
use  of  the  GBUS. 


>  .**  , 


DSH-11  makes  use  of  the  read-through  and  two- level- store- behind 
data  movement  algorithms.  A  request  to  read  a  data  item  is  handled 
by  a  data  cache,  it  is  retrieved  and  sent  to  the  processor.  If  the 
data  item  is  not  in  the  data  cache,  the  request  is  passed  down  to 
lower  storage  levels,  one  by  one.  At  each  storage  level,  the  memory 
request  processor  searches  its  directory  to  determine  if  the 
addressed  data  item  is  in  that  level.  When  the  addressed  data  item 
is  found  at  a  storage  level,  a  block  of  data  containing  the  addressed 
data  item  is  broadcasted  to  all  upper  storage  levels.  Each  upper 
storage  level  then  extracts  a  subblock  from  the  broadcast  that 
contains  the  addressed  data  item.  The  subblock  is  stored  in  the 
storage  level.  To  accomodate  an  incoming  block,  an  existing  block 
may  have  to  be  evicted  from  a  storage  level.  The  way  evicted  blocks 
are  handled  is  referred  to  as  the  overflow  handling  strategy. 

In  a  write  operation,  the  data  block  to  be  updated  is  first  read 
into  the  data  cache.  After  the  data  block  is  updated,  the  data  block 
is  sent  to  the  next  lower  storage  level  which  will  update  the  larger 
block  that  contains  the  data  block.  Thus,  the  effect  of  the  update 
is  propagated  to  lower  storage  levels.  The  two- level- store- behind 
strategy  ensures  that  proper  acknowledges  are  obtained  at  a  given 
storage  level  that  indicates  an  updated  block  has  been  propagated  at 
least  two  storage  levels  down  the  hierarchy.  Thus,  at  least  two 
copies  of  the  updated  data  exist  at  all  times. 
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1. 3  Motivation  of  the  Study 

A  key  issue  in  the  INFOPLEX  design  is  performance  evaluation. 
Because  of  the  complexity  involved  in  the  design  of  the  INFOPLEX 
System,  it  is  not  intuitively  obvious  how  the  performance  of  a  model 
will  be  given  certain  design  specifications.  Various  techniques  have 
been  employed  to  do  performance  evaluation  (Lucas71,  also  INFOTECH 
state  of  the  art  report,  performance  modelling  &  prediction  Vol.l). 
Simulation  and  analytic  models,  among  others,  were  found  most  useful 
in  evaluating  the  design  alternatives  of  INFOPLEX. 


The  simulation  technique  was  employed  (Lam79)  to  obtain  various 
performance  statistics  which  provided  insights  about  INFOPLEX.  The 
results  were  useful,  but  it  was  very  expensive  to  explore  various 
design  issues  using  this  approach.  Buzen  has  indicated  that  : 
(Buzen75) 


”...  A  new  family  of  analytic  model  has  been  developed  which  is 
based  on  the  theory  of  queueing  networks.  These  models  are 
sufficiently  rich  to  represent  all  the  essential  components  of  almost 
any  multi-programmed  computer  system.  In  many  cases,  queueing 
network  models  have  proven  to  be  several  orders  of  magnitude  more 
cost  effective  than  conventional  simulation  models  for  a  variety  of 
performance  evaluation  applications  ...” 


It  seems  logical  to  adopt  analytic  queueing  network  approach  as 


a  design  tool  for  the  performance  evaluation  of  the  INFOPLEX  data 
base  computer  (Madnick80) .  There  are  two  problem  areas  in  using  a 
queueing  network  model,  namely  : 

a.  How  to  map  system  and  workload  features  into  a  queueing  network? 

b.  How  to  solve  queueing  network  problems? 

0 

The  first  area  is  called  modeling;  the  second  one  deals  with 
suitable  methods  of  solution*  The  modeling  question  is  least  well 
understood.  On  the  one  hand,  we  find  extremely  simplified  analytic 
models;  on  the  other  hand,  we  see  the  designers  resorting  to  costly 
highly  imitative  simulations (Reiser78) .  The  major  thrust  of  this 
paper  is  to  develop  a  pragmatic  analytic  tool  for  evaluating  the 
performance  statistics  of  the  INFOPLEX  data  base  computer.  Several 
objectives  were  pursued  : 

1.  To  be  intuitively  understandable. 

2.  To  be  cost  effective. 

3.  To  yield  sufficient  accuracy  for  many  performance  questions 

Buzen's  Operational  Analysis  framework  was  applied  to  model  the 
DSH-11  subsystems  of  the  INFOPLEX  data  base  computer. 
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1.4  OPERational  Analysis (OPERA) 

The  traditional  approach  to  deriving  queueing  network  results 
depends  on  assumptions  used  in  the  the  theory  of  stochastic 
processes: 

*  The  system  is  modeled  by  a  stationary  stochastic  process. 

*  Jobs  are  stochastically  independent. 

*  Transitions  from  device  to  device  are  Markovian. 

*  The  system  is  in  stochastic  equilibrium. 

*  The  service  time  at  each  device  has  an  exponential 
distribution;  and 

*  The  system  is  ergodic,  i.e.  long-term  averages  converge  to 
the  values  computed  for  stochastic  equilibrium. 

The  theory  of  queueing  network  based  on  these  assumptions  is 
usually  called  "markovian  queueing  network  theory”  (Klein75)  . 

However,  some  of  these  concepts  such  as  "equilibrium”  or 
"stationar ity" ,  can  not  be  proved  to  hold  by  observing  the  system  in 
a  finite  time  period.  In  fact,  most  can  be  disproved  empirically  - 
for  example,  in  a  computer  system,  parameters  change  over  time,  jobs 
are  dependent,  device  to  device  transactions  do  not  follow  Markov 
chains,  and  service  distributions  are  seldom  exponential (Buzen78c) . 

By  using  a  different  set  of  assumptions,  operational  equations 
can  be  derived  and  they  are  likely  to  hold  in  actual  systems.  This 
has  been  proved  to  be  true (Buzen76a,b,c, 78c,  and  Denn77) ,  and  is 
referred  to  as  operational  analysis.  Chapter  3  will  review  OPERA  and 
use  it  to  model  INFOPLEX  systems. 


J 


1.5  Multi-Transaction-Type,  Multi-Class  Modeling  Technique 

As  mentioned  in  section  1.3,  there  are  two  problem  areas  to  be 
considered  in  using  a  queueing  network  model.  OPERA  provides  us  with 
a  framework  to  solving  queueing  network  problems.  But  the  problem  of 
mapping  system  and  workload  features  into  a  queueing  network  remains 
unsolved  in  the  INFOPLEX  environment  because  of  the  complexity 
involved  in  the  multi-level  structure  of  DSH-11.  Different  modeling 
techniques  can  be  employed  to  exploit  the  OPERA'S  power.  The  concept 
(Baskett75)  of  multi-class  customers,  among  others,  is  found  to  be 
useful  in  modeling  the  DSH-11  models.  Since  multi-transaction  types 
(read  and  write  transactions  for  example)  are  present  in  the  INFOPLEX 
environment,  the  techniques  to  model  an  multi- transact ion- type  system 
are  also  discussed.  The  multi-class  concept  allows  a  device  to  have 
several  different  classes  of  transactions.  For  each  class, there  are 
distinct  values  for  the  service  times  and  the  routing  frequencies. 
Each  job  belongs  to  exactly  one  class,  and  each  class  is  local  to  a 
specific  device.  Each  class  is  independent  of  one  another  in  the 
sense  that  they  do  not  "talk"  to  one  another. 

The  multi-transaction-type  concept  coupled  with  the  multi-class 
concept  enables  a  modeler  to  decompose  different  types  of 
transactions  into  subsystems.  After  developing  a  queueing  network 
model  for  each  type  of  transaction,  the  different  submodels  can  then 
be  integrated  to  form  the  desired  queueing  network  model.  3.2.2 
describes  the  multi-class  model. 


It  is  interesting  that  by  using  the  multi-class  technique  for 
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modeling  INFOPLEX,  one  can  get  a  diagonally  structured  transition 
matrix  for  the  system,  therefore  can  compute  visit  ratios(the  number 
of  times  a  job  visits  a  device)  by  inspection.  Furthermore,  it  is 
interesting  to  note  that  the  ceiling  throughput  can  be  estimated  by  a 
simple  formula  derived  from  the  reasoning  of  the  multi-class, 
multi-transaction-type  concept. 


1.6  Structure  of  the  Paper 


Chapter  2  surveys  state-of-the-art  analytic  models.  Chapter  3 
reports  modifications  made  to  Buzen's  work (Buzen78c) ,  key 
differences,  computational  procedures,  and  the  results  obtained. 
Chapter  4  reports  RESQ's (Research  Queueing  Analyzer  Program  Package) 
result  which  confirms  the  result  of  the  OPERational  Approach  (OPERA). 
Chapter  5  compares  OPERA'S  results  with  Lam's  simulation  results 
using  comparable  P1L3  (1  processor,  3  levels)  model  of  INFOPLEX  with 
comparable  inputs.  Chapter  6  extends  the  OPERA'S  results  to  a 
general  DSH-11  model  with  R  proportion  of  READ  transactions,  L 
levels,  P  loaclity  reference,  and  bottleneck  service  time  S(b). 
Chapter  7  concludes  this  report  and  indicates  future  directions  along 
this  line  of  work. 


1.7  Summary  of  the  Paper 


The  inventions  and  innovations  of  computer  hardware  and  software 
technologies  together  with  the  needs  for  high  performance,  high 
reliability,  and  nearly  infinite  storage  capacity  computers 
stimulated  research  and  development  of  specialized  architectures  for 


database  management  systems. 


The  INFOPLCX  data  base  computer  proposed  by  Madnick  applies  the 
theory  of  hierarchical  decomposition  to  obtain  a  specialized 
architecture  for  database  management  with  substantial  improvement  in 
performance  and  reliability  over  conventional  architectures. 

A  key  issue  in  the  INFOPLEX  design  is  performance  evaluation. 
Because  of  the  complexity  involved  in  the  design  of  the  INFOPLEX 
system,  it  is  not  intuitively  obvious  how  the  performance  of  a  model 
will  be  affected  by  different  design  choices. 

This  paper  provides  a  cost  effective  and  intuitively  appealing 
solution  technique  for  evaluating  the  performance  of  the  complex 
INFOPLEX  data  base  computer.  By  adopting  the  operational  approach, 
an  intuitive  argument  and  a  cost  effective  solution  can  be  obtained. 
By  using  the  multi-class,  mul ti-transaction- type  modeling  technique, 
a  diagonally  structured  transition  matrix  for  the  INFOPLEX  model  can 
be  constructed  which  leads  to  the  inspectabil ity  of  the  visit  ratios 
to  all  devices.  From  these  visit  ratios,  one  can  compute  the 
bottleneck  device  of  a  closed  system  which  provides  information  about 
the  system's  throughput.  The  system's  response  time  can  be  obtained 
from  Little's  formula  once  the  system's  throughput  and  number  of 
customers  in  the  system  are  known.  The  major  achievements  of  this 
paper  can  be  summarized  as  follows  : 

-  provide  an  intuitive  and  analytically  tractable  method  to 
evaluate  the  performance  of  the  complex  INFOPLEX  data  base 
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computer (chapter  3). 

-  obtain  a  diagonally  structured  transition  matrix  which 
simplifies  the  computation  of  visit  ratios  for  INFOPLEX  by  using  the 
multi-transaction-type,  multi-class  modeling  technique (chapter  3). 

-  validate  OPERA  results  by  the  traditional  stochastic  approach 
implemented  by  RESQ  and  by  the  GPSS  simulation  results  obtained  by 
(Lam79) (chapter  4  and  5). 

-  provide  a  quick  and  handy  way  to  compute  the  maximum 
throughput  of  any  INFOPLEX  model  when  given  a  set  of  (locality 
reference,  number  of  levels,  proportion  of  READ  transactions,  slowest 
device  service  time) (chapter  6). 

-  provide  a  framework  for  future  performance  analysis  of 
INFOPLEX  design  alternatives.  More  complicated  model  can  be  obtained 
by  refining  current  model  to  accomodate  overflow-handling, 
broadcasting,  priorities,  etc... 
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2  Analytic  Model#  State  of  the  Art 


The  theory  of  queueing  networks  has  been  developed  for  more  than 
two  decades.  Queueing  network  models  are  becoming  popular  as  models 
for  performance  analysis  of  computer  systems  and  communication 


networks.  (Buzen78c)  did  an  excellent  summary  of  the  evolvement: 


"...  In  1957,  Jackson  published  an  analysis  of  a  multiple  device 
system  wherein  each  device  contained  one  or  more  parallel  servers  and 
jobs  could  enter  or  exit  the  system  anywhere.  In  1963  Jackson  extended 
his  analysis  to  open  and  closed  systems  with  local  load-dependent 
service  rates  at  all  devices.  In  1967,  Gordon  and  Newell  simplified 
the  notational  structure  of  these  results  for  the  special  case  of 
closed  system.  Baskett,et  al,  extended  the  results  to  include 
different  queueing  disciplines,  multiple  classes  of  jobs,  and 
nonexponential  service  distr ibution(Baskett75) .  The  first  successful 
application  of  a  network  model  to  a  computer  system  came  in  1965  when 
Scherr  used  the  classical  machine  repairman  model  to  analyze  the  NIT 
time  sharing  system, CTSS (Sche67) .  However,  the  Jackson-Gordon-Newell 
theory  lay  dormant  until  1971  when  Buzen  introduced  the  central  server 
model  and  fast  computational  algorithms  for  these  models.  Working 
Independently,  Moore  showed  that  queueing  network  models  could  predict 
the  response  times  on  the  Michgan  Terminal  System  to  within  10  percent. 
Extensive  validations  since  1971  have  verified  that  these  models 
reproduce  observed  performance  quantities  with  remarkable  accuracy..." 


(Buzen78a)  proposed  OPERA  as  an  alternative  to  stochastic 
modelling.  A  framework  of  the  OPERA  models  is  detailed  in  (Buzen78b)  . 
In  that  paper,  the  operational  approach  to  queueing  network  model  is 
outlined.  The  operational  analysis  assumptions  can  be  tested,  the 
analysis  is  much  more  intuitive  and  tractable  by  human  mind,  and  there 
are  good  reasons  to  believe  that  they  often  hold. 


The  applications  of  analytic  models  to  the  performance  analysis  of 
computer  systems  has  become  more  and  more  prevalent.  Some  researchers 
continue  to  use  the  traditional  approach(Lavenberg80,  Reiser80, 
ChandySO,  and  Bard80  for  instances);  others  try  to  use  operational 
analysis  to  study  the  properties  of  queueing  netwrok  models  (Buzen, 
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Denning80).  Since  the  introduction  of  operational  analysis  in  1976  as 
an  alternative  to  stochastic  modeling,  many  informal,  intuitive 
arguments  used  to  motivate  stochastic  theorems  become  rigorous  proofs 
in  the  formal  context  of  operational  analysis.  Besides  simplifying 
derivations,  operational  analysis  extends  stochastic  theorems  by 
demonstrating  their  validity  in  cases  where  conventional  stochastic 
assumptions  cannot  be  justified.  Moreover,  operational  analysis  has 
led  to  new  results  about  sensitivity  factors  and  error  bounds.  These 
results  are  particularly  valuable  for  prediction  because  the  future 
validity  of  operational (or  stochastic)  assumptions  is  usually 
uncertain (Buzen80) . 

From  the  application  point  of  view,  OPERA  has  a  lot  of  significant 
advantages  over  the  traditional  stochastic  approach  -  not  only  because 
it  gives  operationally  testable  variables,  but  also  for  its  intuitive 
arguments  which  make  the  results  much  more  convincing  to  the  modeler. 
With  this  approach,  it  is  possible  to  use  the  queueing  network 
technology  with  much  more  confidence  and  understnad ing .  This  paper 
adopts  this  approach.  Chapter  three  reviews  OPERA  and  some  modelling 
techniques  for  DSH-11. 


3  OPBRational  Analysis  Approach  (OPERA) 

In  this  chapter,  we  first  discuss  the  framework  proposed  by  Buzen, 
and  the  computational  procedures  for  open  and  closed  systems  under  the 
INFOPLEX  environment.  Then  the  notion  of  mulit-class  queueing  network 
model  for  operational  analysis  is  introduced.  The  notion  of 
multi-class  queueing  network  model  uses  the  same  idea  as  single-class 
queueing  network  models  but  has  several  classes  of  transactions  for 
each  device.  Algorithms  are  developed  to  fit  the  multi-class  notion. 
The  multi-class  concept  lends  itself  to  a  diagonally  structured 
transition  matrix,  henceforth  simplifies  the  computational  complexity 
because  of  the  inspectabil ity  of  the  structure.  Finally  we  extend  the 
multi-class  queueing  network  model  from  a  single-transaction-type 
environment  to  a  multi-transaction-type  environment  and  compute  the 
performance  statistics  of  P1L3  model  of  INFOPLEX. 

3. 1  Single-Transaction-Type,  Single-Class  Queueing  Network  Model. 

(Buzen78c)  has  proposed  the  framework  of  the  operational 
analysis  of  queueing  network  models.  The  framework  is  sufficiently 
rich  to  represent  all  the  essential  components  of  almost  any 
multi-programmed  computer  systems.  We  use  this  framework  as  the 
basis  for  the  analysis  of  this  paper. 

Since  it  is  much  simpler  to  discuss  an  environment  which 
possesses  only  a  single  type  of  transactions,  we  introduce  the 
concept  of  a  single-transaction-type  model  versus  a 
multi-transaction-type  model.  A  multi-transaction-type  model  is  a 
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variation  of  the  single-transaction-type  model  in  the  sense  that  it 
uses  the  result  established  by  the  single-transaction-type  model  to 
model  the  multi-transaction-type  environment.  For  instance,  in  a 
central  server  model,  different  transaction  types  can  be  combined 
into  a  single  type  transaction  by  using  weighted  averages  as 
parameters.  Since  the  routes  that  different  types  of  transactions 
travel  within  the  central  server  model  are  similar,  this  kind  of 
combination  to  a  single-transaction-type  model  suffices. 

3.1.1  Operational  Measures  Proposed  by  Buzen. 

3. 1.1.1  Model  Description 

Fig-3.1.1  shows  two  of  K  devices  in  a  multi-resource 
network.  A  job  enters  the  system  at  IN.  It  circulates 
around  in  the  network,  waiting  in  queues  and  having  services 
requests  processed  at  various  devices.  When  done,  it  exits 
at  OUT.  The  network  is  operationally  connected  in  that  each 
device  is  visited  at  least  once  by  some  job  during  the 
observation  period. 

A  job  is  "in  queue"  at  device  i  if  it  is  waiting  for  or 
receiving  service  there.  We  let  n(i)  denote  the  number  of 
jobs  in  queue  at  device  i,  and  N  *  n(l )+. . .+n(k)  denote  the 
total  number  of  jobs  in  the  system.  The  system  output 
rate,X(o) ,  is  the  number  of  jobs  per  second  leaving  the 
system.  If  the  system  is  open,  X(o)  is  externally  specified 
and  N  varies  as  jobs  enter  or  leave  the  system.  If  the 
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system  is  closed/  the  number  of  jobs  N  is  fixed.  This  is 
modeled  by  connecting  the  output  back  to  the  input,  as 
suggested  by  the  dashed  arrow  in  Fig-3.1.1. 

An  analysis  of  an  open  system  assumes  that  X(o)  is 
known  and  seeks  to  characterize  the  distribution  of  N.  An 
analysis  of  a  closed  system  begins  with  N  given  and  seeks  to 
determine  the  resulting  X  (o)  along  the  OUT/IN  path.  System 
response  time, util iza tion  rate,  mean  queue  length,  and 
response  time  for  each  device,  are  sought  in  both  cases. 

3. 1.1. 2  Basic  Notation  ' 

K  :  #  of  devices  in  the  system,  k~l,2,...,K 

N  :  denote  the  total  #  of  jobs  in  the  system  where  N  * 
n(l)+n(2)+. . .+n{k) 

X (o) :  The  system  output  rate.  It  is  the  number  of  jobs  per 
second  leaving  the  system. 

T  :  An  observation  period  that  the  system  is  measured. 

R(or  R(o))  :  denotes  the  system's  response  time. 

For  each  device  k  »  1,2,...,K  : 

n(k)  :  the  number  of  jobs  in  queue  at  device  k.  It  is  the 
queue  length  at  device  k;  it  includes  jobs  waiting  and 
receiving  services 

A(k)  —  #  of  arrivals  during  the  observation  period. 

B(k)  ~  total  busy  time  (  time  during  which  n(k)  >  0  ) 

X  (k)  *  Throughput  of  device  k. 

R(k)  :  Response  time  of  device  k. 
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C ( i r j )  —  #  of  times  a  job  requests  service  at  device  j 
immediately  after  completing  a  service  request  at  device  i. 

q(i/j)  —  routing  frequency,  the  fraction  of  jobs  proceeding 
next  to  device  j  on  completing  a  service  request  at  device 
i. 

If  we  treat  the  "outside  world"  as  device  "o" ,  we  can  define 
also  : 

A(o,j)  —  4  of  jobs  whose  first  service  request  is  for 
device  j. 

C(i,o)  —  4  of  jobs  whose  last  service  request  is  for  device 
i  • 

a(k)  —  arrival  rate  at  device  k.  /*  a(k)»A(k)/T  */ 

a(o,j)  —  arrival  rate  at  device  j  from  the  "outside  world" 
/*  a(o,j)»A(o,j)/T  */ 

Q  (k)  —  queueing  time  at  device  k. 

Nbar,  nbar(k)  denote  the  mean  values  of  N  ,  n(k)  ... 

C(k)  »  C(i,l)+C(i,2)+...+C(i,K) 

C  (o)  «  C(0,o)+C(l,o>  +  .  ..+C(K,o) 

S  (k)  :  mean  service  time  of  device  k 

V(k)  ■  X(k)/X(o);  the  visit  ratio  of  a  job  to  device  k. 

3. 1.1. 3  Assumption 

The  model  assumes  that  no  jobs  overlap  its  use  of 
different  devices.  In  practice,  few  application  programs 
ever  achieve  more  than  a  few  percent  overlap  between  CPU  and 
I/O  devices;  the  error  introduced  by  this  assumption  is 
usually  not  significant.  The  model  also  assumes  that  a 
device  is  busy  if  a  request  is  pending  there  —  no  part  of 
the  system  can  block  progress  in  another  part.  This 
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assumption  is  not  met  by  all  real  systems;  for  example,  the 
CPU  might  be  unable  to  continue  if  an  I/O  buffer  is  full. 

We  will  assume  that  C(o,o)»0  because  otherwise  there  would 
be  jobs  that  used  no  resources  before  departing.  However, 
it  is  possible  that  C(k,k)  >  0  for  any  device  k  since  a  job 
could  request  another  burst  of  service  from  a  device  which 
had  just  completed  a  request  from  that  job. 

The  system  must  be  flow  balanced  —  i.e.  the  number  of 
arrivals  at  a  given  device  must  be(almost)  the  same  as  the 
number  of  departures  from  that  device  during  the  observation 
period. 

The  device  must  be  homogeneous  —  i.e.  the  routing  of 
jobs  must  be  independent  of  local  queue  lengths,  and  the 
mean  service  time  at  a  given  device  must  not  depend  on  the 
queue  lengths  of  other  devices. 

3. 1.1. 4  Performance  Statistics  Computation 

The  number  of  completions  at  device  k  is  : 

C(k)  -  C(k,0)+C(k,l)+C(k,2)+...4C(k,K)  k«l,2,...,K. 

The  number  of  arrivals  to,  and  departures  from  the 
system  is: 

A(o)  -  A(o,l)+...+A(o,K) 

C  (o)  -  C(l,o)  +  ...+C(K,o) 

From  Fig3.1.1  it  is  clear  that  A(o)  »  C(o)  in  a  closed 
system.  In  an  open  system  which  reaches  steady  state  but 
not  fully  utilized,  we  also  have  A(o)*C(o). 
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In  terms  of  B(k) ,C(k) ,  four  derived  operational 
quantities  are  defined  : 

U(k)  «B(k)/T. 

S  (k)  »  B(k)/C(k) 

X(k)»  output  rate  of  requests  from  device  k  «  C(k)/T 
Note  that,  for  any  k,  q (k,o)+q(k,l)+. . ,+q(k,K)=l . 

Job  Flow  Analysis 


Given  the  mean  service  times  S(k)  and  the  routing 
frequencies  q(k, j) ,  how  much  can  we  determine  about  overall 
device  completion  rates  X(k)  or  response  times  R(k)  ?  These 
questions  are  usually  approached  through  the  operational 
hypothesis  known  as  the  Principle  of  Job  Flow  Balance;  For 
each  device  k,  X(k)  is  the  same  as  the  total  input  rate  to 
device  k.  This  principle  will  give  a  good  approximation  for 
observation  periods  long  enough  that  the  difference  between 
arrivals  and  completions, A(k)-C (k)  is  small  compared  to 
C(k) .  It  will  be  exact  if  the  initial  queue  length  is  the 
same  as  the  final  length.  Choosing  an  observation  period  so 
that  the  initial  and  final  states  of  every  queue  are  the 
same  is  not  inappropriate. 

When  a  job  flow  is  balanced,  we  refer  to  the  X(k)  as 
device  throughput.  The  Flow  Balance  Principle  can  be 
expressed  as:  C(k)-A(k)  k*0,l,...,K. 


We  can  also  obtain  X(k)  ■  X(o)q(o,k)  +  X(l)q(l,k)  +  ... 


Define  V(k)  *X  (k)  /X  (o)  and  call  V(k)  the  visit  ratio  to 
device  k,  we  immediately  get  V(k)  ■  q(o,k)  +  V(l)q(l,k)  + 

...  +  V(k)q(K,k)  f  o  r  k»0 ,  1 , . . . ,  K 

If  the  network  is  open,  the  value  of  X(o)  is  externally 
specified  and  these  equations  will  have  a  unique  solution 
for  the  unknowns  X(k).  However,  if  the  network  is 
closed, X(o)  is  initially  unknown,  and  the  equations  have  no 
unique  solution  because  the  sum  of  the  X(k)  equations  for 
k«l,...,K  reduces  to  the  X(o)  equation.  Therefore,  in  a 
closed  network,  there  are  K  independent  equations  but  K+l 
unknowns.  Nonetheless,  the  job  flow  balance  equations 
contain  information  of  considerable  value.  In  particular, 
when  a  bottleneck  situation  occurs,  the  X(o)  of  a  closed 
system  can  be  obtained  by  setting  the  utilization  of  the 
bottleneck  device  to  one. 

Utilization  Rate 

U(k)-B(k)/T«{C(k)/T}*{B(k)/C(k)  }  holds  for  each 
devicee.  Therefore, 
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Response  Time  at  Each  Device 


To  compute  R(k)  for  device  k,  consider 


R(k)*Q  (k)+S  (k) 

What  is  Q(k)  ? 

Consider  the  instant  a  job  Y1  departs  from  device  kr 
and  job  Y2  arrives  at  device  k  : 

R(k)  ■  time  spent  in  device  k.  a(k)*R(k)  »  number  of 
jobs  that  arrived  after  job  X  arrived  and  up  to  the  instant 
job  X  departs. 

{a(k) *R  (k) }*S  (k)  ■  time  to  process  backlog  before  job  Y2  can 
be  processed.  ■  queueing  time  for  job  Y2. 

So  on  average,  Q(k)  ■  a(k)  *R  (k)  *s  (k) 
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Nbar  »  nbar(l)  +  nbar(2)  +  ...  +  nbar(K)  «R(1)*X(1)  + 

R  (2 )  *X  (2 )  +  ...  +  R(K)*X(k) 

therefore,  R  -  Nbar/X  (o)  »  {R(1)*X(1)  +  R(2)*X(2)  + 

R  (3 )  *X  (3 )  +...  +R  (k)  *X  (k)  }/X  (o) 

Notice  that  Little's  formula  does  not  depend  upon  any 
specific  assumptions  regarding  the  arrival  distribution  or 
the  service  time  distribution;  nor  does  it  depend  upon  the 
number  of  servers  in  the  system  or  upon  the  particular 
queueing  discipline  within  the  system.  In  the  derivation  of 
Little's  formula,  the  boundary  around  a  queueing  system  is 
not  precisely  defined,  therefore  the  formula  can  be  applied 
to  the  entire  queueing  system  as  well  as  to  a  single 
queue (Klein75) . 


INPUT  STEP  OPERATING  EQUATION  OUTPUT 

N  1.  V  (o)  -  1 

compute  V(k)«V(0)q(0,k)  +  ...+V(K)q(K,k)  V(k)'s 

q(k,j)  k  «  1 , 2, . . . ,  K  k»l,...,K 

S(k)'s  2.  compute  V(b)*S(b)  =  max{  (V  (k)  S  (k)  } 

3.  X(o)«l/{V(b)  *S  (b)  }  X  (o) 

4.  Compute  U  (k)  *X  (o)  V  (k)  S  (k)  ,  k«l,...,K  U(k)'s 

5.  R«  N/X  (o)  R 

X(o)  is  the  maximum  throughput  given  N. 

R  is  the  corresponding  system's  response  time. 


R  and  X (o)  give  the  performance  of  the  system  given  the  input  workload. 
U(k)  gives  us  the  utilization  rate  of  device  k. 


3.1.3  Computational  Procedure  for  Open  System. 

For  an  open  system  with  single  transaction  type  in  steady  state 
which  satisfies  job  flow  balance  hypothesis,  we  have  the  following 
interesting  and  intuitive  results  : 

X(o)-C(o)/T»{C(o,0)+C(o,l)+. . .+C (o,K) }/T-{A(o,0)+. . .+A(o,K) }/T=a(o,0)+. 

. .+a(o,K) 


Hence  X(o)  is  externally  specified  in  an  open  system. 


The  results  are  as  follows: 


oV\  ■' vv  W',’ 
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j  K  devl ces 
M  classes/device 
N  jobs 
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S(k)'s  3.  U(k)«X  (k)  *S  (k) 

k«l , . . .  ,K 

If  U(k)  >1  for  some  k,  then  quit.  U(k)  >  1. 

4.  R(k)-S  (k)/{l-X  (k)S  (k)  }  R (k) 

k*l f  .  .  •  , K  k*l ,  .  •  •  f K 

5.  R«{R(l)*X(l)  +  ...+R(K)*X(K)}/X(o)  R 

6.  nbar (k) »R  (k)X  (k)  nbar(k) 

k»l k*l ,  . . .  ,K 

7.  Nbar  *  nbar (1 )+. . . +nbar (K )  Nbar 


R  is  used  to  measure  how  fast  the  system's  response  is.  Note  that 
Nbar*X(o)*R  should  hold  which  serves  as  a  check. 

U(k)fR(k)r  and  n(k)  are  used  to  see  how  busy  a  device  is.  If  U  (k)  and 
n(k)  are  large,  then  chances  are  we  have  to  improve  the  performance  of 
that  device. 

3.2  Sinqle-Transaction-Type,  Multi-class  Queueing  Network  Model. 

3.2.1  Introduction 


■'V 


$ 


The  open/closed  System  computational  procedures  developed  in 
the  previous  sections  share  the  same  problems  that  the  estimations 
of  S(k)  and  q(k,j)  do  not  follow  the  real  situation.  Re-estimation 
is  necessary  in  both  open  and  closed  systems  which  decreases  an 
evaluator's  confidence  in  his  results. 
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A  job  visits  CPU  4  times  and  disk  3  times  before  it  exits  the 
system.  Since  V(o)«l,  therefore,  V(1)»4,V(2)»3.  Hence 
q(o,l)*l,q{l,o)>. 25,  q(l,2)-.75  have  to  be  estimated  accurately  in 
order  to  obtain  V(l)*4  and  V(2)»3.  In  this  case,  estimation  of 
q(i,j)  is  easily  done.  However  ,  in  a  general  queueing  network, 
the  task  of  estimating  q(k,j)  is  no  longer  intuitively  obvious. 
Further,  an  evaluator  would  also  feel  very  uncomfortable  with 
estimating  S  (k) .  In  this  section,  a  model  with  single  transaction 
type  using  multi-class  concept  is  developed  to  accommodate  this 
shortcoming . 

3.2.2  Model  Description 

Fig-3.2.1  shows  two  of  the  K  devices  in  a  multi-device, 
multi-class  per  device  queueing  network.  A  job  enters  the  system 
at  IN.  it  circulates  around  in  the  network,  waiting  in  queue  and 
having  service  requests  processed  at  various  devices.  When  done, 
it  exits  at  OUT.  The  difference  is  that  each  device  has  m 
different  classes  of  customers.  Each  job  belongs  exactly  to  one 
class  of  the  device  when  it  visits  the  device.  Each  class  has  its 
own  service  time  and  routing  probabilities.  Jobs  arrive  at  a 
device  as  member  of  a  particular  class.  During  a  visit  at  a 
device,  a  job  does  not  change  its  class  membership.  Each  class  can 
be  given  a  unique  number  within  the  system. 

Let's  consider  the  CPU-Disk  example  again.  By  applying  the 
multi-class  idea,  we  can  model  it  as  in  Figure  3.2.2: 
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It  seems  that  we  have  complicated  the  situation,  but  actually 
not.  This  method  offers  us  the  following  nice  and  neat  properties: 


1.  It  is  more  natural:  a  transaction  will  flow  through  the  system 
without  being  modified.  Therefore,  we  do  not  have  to  worry  about 
re-estimating  or  weighting  the  service  time  before  we  know  their 
visit  ratios.  Each  visit  is  assigned  to  exactly  one  class. 


2.  The  routing  rules  are  very  clear  to  a  modeler  because  it 
follows  the  natural  job  flow  path.  For  instance,  in  the  example 
given. 


q(o,l)-q(l,2)-q(2,3)*q(3,4)-q(4,5)»q(5,6)»q(6,7)»q(7, 0)-l 


q(k,j)»0  otherwise. 


Note  that  k  in  q(k,j)  refers  to  class  number  instead  of  device 
number  now. 


This  nice  property  enables  us  to  solve  for  the  visit  ratios  to 
each  device  by  inspection.  The  transition  matrix  of  such  a  system 
turns  out  to  be  almost  diagonal.  Section  3.4  gives  the  details. 


Since  we  give  each  class  a  unique  number,  each  class  can  be 
considered  as  an  independent  service  station  so  that  all  the 
operating  equations  developed  in  the  single-class  model  still  holds 
in  this  multi-class  model  provided  that  the  total  utilizations  of 
the  classes  of  a  device  sums  up  to  less  than  one. 


wsnsrz' 
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3.2.3  Computational  Algorithm  for  Closed  System 


Let  c,i,j  stand  for  classes  and  k  for  device.  Define 


utilization  rate  of  device  k. 

utilization  rate  of  class  i  to  its  corresponding  device  . 
visit  ratio  of  class  i  to  its  corresponding  device, 
service  time  of  class  i  to  its  corresponding  device, 
the  #  of  visits  to  device  k. 
the  average  service  time  of  device  k. 

C  :  the  total  t  of  classes  in  the  network, 
o  :  stands  for  the  system  or  initial  value, 
b  :  stands  for  the  bottleneck. 


U  (k) 
u(i) 
V(i) 
S(i) 
Z(k) 
D(k) 


INPUT 


STEP  Operating  Equation 


OUTPUT 


q(i# j) 's 


V(o)-l 


compute  V(  j)«V  (l)q(l,  j)+V  (2)q(2,  j) 
+  .  ..+V(C)q(C,j)  ,  j*l,...,C 


S  (i)  's 


N 


compute  Z{k)D(k)  *  ZZ  V  (i)S  (i) 
k=l,...,K 

Z  (b)D  (b)  -  Max  ( Z  ( k) D  (k)  )  k  in  K. 
X(o)  =  1/Z (b)D  (b) 
compute  u(i) ,i«l, .. .,C 
U(k)  =  X.  u(i)  ,  k«l,...,K 

itk 

Compute  R«N/X(o) 


U  (k) ,k*l , . . .  fK 
R 


3.  3  Multi-Transact ion-Type ,  Multi-Class  Queueing  Network  Model 


3.3.1  Motivation 


We  have  limited  our  discussion  to  the  single  transaction  type 
queueing  network  systems  which  have  either  closed  or  open  forms. 

In  practice,  there  are  normally  many  types  of  transactions  that  are 
being  processed  inside  a  computer  system.  For  instance,  consider 
the  Baybank's  X-press  24  hour  service  system  which  has  to  process 
cash  withdraw,  account  balance,  saving  deposit,  etc.  Management 
may  want  to  know  the  system's  overall  response  time  as  well  as  each 
transaction's  response  time  upon  a  customer's  request.  In  a  highly 
parallel  computer  systems,  there  are  also  many  types  of 
transactions  being  processed  simultaneously.  Therefore,  it  is 
desirable  to  have  a  general  queueing  network  model  to  accommodate 
multiple  transactions.  One  way  to  achieve  this  is  to  compute  the 
weighted  average  service  time  and  the  weighted  routing 
probabilities  of  all  the  transactions.  Then  treat  the  system  as  a 
single- transact ion  type  system  and  apply  the  results  that  we 
developed  previously  for  the  single-class  model  to  obtain  the 
response  time  for  each  device  and  hence  for  each  transaction  type. 

This  method,  however,  has  two  disadvantages  : 

i 

1.  The  routing  rules  for  different  transaction  types  are  • 

different,  especially  in  a  highly  parallel  computer  system.  By 
merging  different  transaction  types  into  a  single  transaction  type, 
we  also  have  to  subjectively  re-  estimate  the  routing  frequencies  ^ 

which  will  distort  the  real  system  we  want  to  model.  It  may  be  ; 

easy  to  estimate  the  S(i)'s  and  q(i,j)'s  for  the  first  level 

\ 

devices,  but  certainly  not  clear  to  the  lower  level  devices. 

| 
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2.  The  model  evaluator  has  to  estimate  the  average  of  the 
average  of  transactions  which  reduces  his  confidence  in  the 
results.  It  is  clear  that  the  result  obtained  from  this  method 
will  not  be  satisfactory .We  will  explore  another  method  in  the 
following  subsection. 

3.3.2  Modeling  Technique 

In  a  multi-class  model,  the  multi-transaction  type  system  can 
be  modeled  easily  by  simply  considering  the  transaction  types  as 
different  classes  of  customers  that  do  no  "talk”  to  one  another. 

We  briefly  describe  this  idea  for  closed  system  here: 

In  a  closed  system,  the  number  of  customers  in  the  system  is 
fixed.  There  are  several  ways  of  modeling  the  problem  using  our 
single  transaction  type  multi-class  model.  To  list  two  of  them  : 


1.  Form  a  closed  chain  for  each  of  the  transactions. 

2.  Assign  probabilities  to  each  of  the  transaction  types  and 
form  a  single  closed  chain. 

Note  that  in  the  first  approach,  the  throughput  of  each 
transaction  type  may  not  follow  some  given  quota  but  it  will  give 
us  the  best  mix  of  transaction  types.  In  the  second  approach,  the 
transaction  will  follow  a  given  quota  which  enables  us  to  study  the 
affect  when  given  a  mix  of  transaction  types. 


i 

v| 
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To  study  the  interactions  among  transaction  types,  we  can 
close  other  chains  and  single  out  a  closed  chain  if  the  first 
approach  is  used  or  set  probabilities  to  one  for  the  interested 
transaction  type  if  the  second  approach  is  used.  Interactions 
among  transactions  can  then  be  studied  by  checking  whether  they  are 
additive. 


We  apply  the  second  approach  using  the  multi-class  model  to 
the  P1L3  model  of  INFOPLCX  with  locality  =*  .6  ,  read  *  70  percents, 
The  results  are  shown  in  the  next  section. 


Note  that  the  results  are  identical  to  the  result  from  chapter 
4  where  RESQ  is  employed  to  compute  the  performance  statistics  for 
the  same  model.  Hence,  RESQ  will  serve  as  a  validation  for  OPERA 
and  on  the  other  hand,  OPERA  can  serve  as  a  tool  to  communicate 
with  and  to  convince  management  as  well  as  an  easy  way  to  study  the 
performance  of  INFOPLEX. 


w 


PAGE  35 


Figure  1.4.2 

DEGREE  OF  MULTI  PROGRAMING  OF  A  CPU  *  20 
SIZES  OF  DATA  QUEUES  (XQ  AND  YQ)  *  10 
DIRECTORY  SEARCH  TIME  =  200  NANOSEC. 

read/write  time  of  a  L(l)  storage  device  *  100  nanosec. 
read/write  time  of  a  L(2)  device  *  1000  nanosec. 
read/write  time  of  a  L(3)  device  =  10000  nanosec. 
bus  speed  *  10  MHZ 

BUS  WIDTH  *  8  BYTES 

SIZE  of  a  transaction  without  data  ®  8  BYTES 
BLOCK  SIZE  AT  L(l)  *  8  BYTES 
BLOCK  SIZE  AT  1(2  *  128  BYTES 
BLOCK  SIZE  AT  L(3)  *  1024  BYTES 
Z  read  requests  8  70Z 
X  WRITE  REQUESTS  *  30Z 

CONDITIONAL  PROB.  OF  FINDING  DATA  IN  a  LEVEL 
GIVEN  THAT  THE  DATA  IS  NOT  IN  ANY  UPPER  LEVEL  =  P 


3.4  Computational  Results  of  P1L3  Model  of  INFOPLEX  Data  Base 
Computer. 


The  P1L3  architecture  is  shown  in  Fig3.4.1  .  The  model  is  highly 
parametized.  Parameters  for  the  P1L3  model  are  chosen  to  reflect  1979 
processor  and  storage  technology.  Two  key  parameters  that  characterize 
the  references  are  the  locality  level  and  the  proportion  of  read  and 
write  requests  in  the  reference  stream.  The  locality  level  (p)  is  the 
conditional  probability  that  a  reference  is  satisfied  at  a  given 
storage  level  given  that  the  reference  is  not  satisfied  in  all  upper 
storage  levels.  The  concept  used  in  3.3  is  applied  to  the  P1L3  model 
using  p>.6  and  70  percent  read  transactions.  Fig3.4.2  summarizes  all 
the  model  parameters. 

The  degree  of  multiprogramming  is  the  maximum  number  of  requests 
that  can  be  active  at  a  CPU.  In  the  corresponding  queueing  network 
model ,  the  degree  of  multiprogramming  is  used  as  the  number  of 
customers  inside  a  closed  system.  The  block  size,  bus  speeds,  bus 
width  and  speeds  of  the  devices  are  parametized.  We  describe  the 
mapping  of  the  P1L3  model  and  workload  features  into  a  queueing  network 
model  in  the  next  section. 

3.4.1  Queueing  Network  Model  Description 

A  mapping  of  the  P1L3  model  and  its  workload  features  into  a 
queueing  network  model  is  shown  in  Fig3.4.3.  Read  operation  and 
write  operation  are  modelled  separately  by  the 
single-transaction-type,  multi-class  modelling  technique.  The 
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logic  of  the  model  is  discussed  in  Chapter  5,  appendix,  and  briefly 
reviewed  in  1.2.  We  highlight  the  modeling  technique  by  discussing 
some  of  the  operations. 

A  request  to  read  a  data  item  is  handled  by  a  data 
cache (Dll, device  1)  which  has  a  directory  service  time  REX  (class  1 
customer) ,  it  is  retrieved  (  retrieve  time  for  Dll)  at  a  read 
service  time  DEX11  (class2  customer)  and  sent  to  the 
processor (class49  which  connects  READ  &  WRITE  operations  together). 
This  probability  is  characterized  by  Locality  Reference (or  p) .  If 
the  data  item  is  not  in  the  data  cache(i.e.  not  in  device  1),  the 
request  is  passed  down  to  lower  storage  levels,  one  by  one. 
Therefore,  there  is  (1-p)  probability  that  the  read  operation  pass 
down  to  LBUS1  (device  2)  which  has  a  message  transfer  time 
REXM(class3  customer) .  If  the  data  item  is  found  in  the  next 
level,  it  is  returned  through  K1 (device  3)  back  to  Dll(classl5 
customer  with  service  time  DEX11)  and  sent  to  the  processor  else 
the  request  is  passed  down  to  the  next  lower  storage  level.  This 
is  the  basis  for  the  mapping  of  the  P1L3  READ  operation  and 
workload  features  into  a  queueing  network  model. 

In  a  write  operation,  the  data  block  to  be  updated  is  first 
read  into  the  data  cache (Dll, class32  customer  with  service  time 
DEX11).  After  the  data  block  is  updated,  the  data  block  is  sent  to 
the  next  lower  storage  level  through  LBUS1  (device2) ,K1 (device 
3)  ,GB US (device  4),K2 (device  5 ) , LB US 2 (device  6, class  37), 

RRP2 (device  7),  back  to  LBUS2 (device  6, class  39),  then  to 

D21  (device  11).  Thus,  the  effect  of  the  update  is  propagated  to 
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Fig3  .4  .4 
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til 


lower  storage  levels. 


As  mentioned  in  3.3,  the  read  submodel  and  the  write  submodel 
can  be  connected  by  a  dummy  device(device  13)  with  zero  service 
time(see  the  front  end  of  the  write  operation) .  Class  49  is  used 
to  connect  the  read  and  write  operations  together.  R  proportion  of 
the  transactions  coming  into  the  system  are  dispatched  to  the  read 
submodel  while  (1-R)  proportion  of  the  transactions  go  to  the  wirte 
submodel . 


This  modeling  technique  ensures  a  clean  decomposition  among 
different  transaction  types. 


Note  that  the  class  number  can  be  used  to  help  walking  through 
the  model.  For  instance,  in  the  write  model,  class  32  customer  is 
serviced  at  Dll,  then  becomes  class  33  customer,  serviced  by  LBUS1 
->  class  34  ->  class  35  ->  class  36  ->  . . .  ->  48  ->  49.  This  is 
also  the  key  to  the  diagonally  structured  transition  matrix. 


3.4.2  Computational  Results 


The  computational  results  are  shown  below  : 


Compute  V (c)  : 

From  Fig3.4.4  we  see  that  given  locality 

V (c»l )*. 7,  V(c-2)-.42 
V(c-3)»V(c-4)-...W(c-8)-.28 
V(c-9)-V(c-10)-...*V(15)-.168 
V(c-16)«V(c-17)-. .  ,wV(c-31)-.112 
V(c-32)-V(c-33)-.  ..-V(c«48)«.3 


.6,  read  »70% 
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2.  Compute  X(o)  :  compute  Z(k)D(k)  for  all  devices 
*>  Z (k*12)D  (k*12)  is  the  bottleneck. 

Z(b)D(b)-V(c«23)S  (c-23)+V  (c*48)S  (c*48) 

X  (o)  *1/{Z  (b)D  (b)  }  ->  X(o)*l/{. 112*10000+. 3*10000}  *  1/4120 
•243  transactions/milli-sec 

therefore,  throughput  is  243  transactions  per  mill i-second . 

3.  Compute  U(k)  for  device  k  D(k)  : 


d(l) 

class* 

1 

2 

15 

32 

S  (c) 

200 

100 

100 

100 

V  (c) 

.7 

.42 

.168 

.3 

U(c) 

.0340 

.0102 

.0041 

.0073 

U  (k»l) 

.056 

D<2) 

class* 

3 

33 

S(C) 

100 

100 

V(C) 

.28 

.3 

U(C) 

.0068 

.00728 

U  (k»2) 

.014 

D(3) 

class* 

4 

14 

34 

S(c) 

100 

100 

100 

V(c) 

.28 

.168 

.3 

U(c) 

.0068 

.00408 

.00728 

U  (k*3 ) 

.018 

• 

D(4) 

class* 

5 

13 

18 

26 

35 

43 

S  (c) 

100 

100 

100 

1600 

100 

1600 

V(c) 

.28 

.168 

.112 

.112 

.3 

.3 

U(c) 

.0068 

.00408 

.0027 

.0435 

.00728 

.1165 

U  (k«4) 

.181 

D(5) 

class* 

6 

12 

17 

27 

36 

42 

S  (c) 

100 

100 

100 

100 

100 

100 

V(c) 

.28 

.168 

.112 

.112 

.3 

.3 

U(c) 

.0068 

.0041 

.0027 

.0027 

.00728 

.00728 

U(k-5) 

.031 

By  the  same  token,  we  get 

U(k-6)«.237 
U (k*7)«.034 
U  (k*8)». 0127 
U  (k-9)«.282 
U(k-10)-.020 
U  (k*ll )*. 141 

U(k-12)*1.0  - —  the  bottleneck  of  the  system. 

4.  Compute  R4)A(o)  ->  R-20/{l/4120}  -  82400 

i.e.  The  system's  response  time  is  82.4  micro-sec. 


Page  43 


4  The  RESQ  Results  Using  P1L3  Model  of  IMFOPLEX. 

RESQ (research  queueing  analyzer)  is  a  program  package  developed  by 
M.  Reiser  and  C.H.  Sauer  which  provides  the  modeller  with  efficient 
methods  of  solution  for  a  spectrum  of  queueing  models  of  varying 
complexity,  ranging  from  analytically  tractable  separable  networks  to 
rather  general  stochastic  models.  QNET4  is  a  subpackage  of  solution 
techniques  of  RESQ.  It  attempts  to  make  available  the  most  general 
class  of  queueing  networks  for  which  an  efficient  analytic  solution  can 
be  obtained.  This  class  is  characterized  by  the  existence  of  a  product 
form  solution.  In  order  for  a  queueing  network  to  have  a  product  form 
solution,  certain  restrictions  have  to  be  imposed: 

-  stochastic,  state  independent  routing  . 

-  no  explicit  priorities. 

-  full  accessibil ity (e.g .  no  blocking  or  finite  queues) . 

-  exponential  service  time  distribution  and  poisson  source. 

General  service  time  distributions  are  compatible  with  certain  queue 
disciplines.  In  this  paper,  we  use  QNET4  solution  technique  to  obtain 
results  for  the  P1L3  model  with  the  same  model  specifications.  The 
queueing  network  model  used  is  the  same  as  Fig3.4.3  .  We  show  the 
program  for  RESQ  and  the  results  computed  from  RESQ. 

4.1  Model  Description  and  Program. 

The  queueing  network  model  that  maps  the  P1L3  system  and  the 
corresponding  workload  features  is  exactly  the  same  as  3.4.1  (see 
Fig3.4.3).  This  is  intentionally  done  in  order  to  make  comparisons 
between  different  methods.  The  RESQ  program  is  shown  in  Fig4.1.1  and 
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TYPE  P1L3RW  RQIOLOG 
METHOD SUNCT 

OPEN  CHAlfJSS  O 
CLOSED  chains: 1 
UUEUCSSIJ 
CLASSES SAM 
COMMENTS? • YUS 

COMMENT :P1L3. WITH  mead  and  write  operations 
CHAIN  I*  TYPE • CLOSED 

COMMENT :USfc  49  TO  CONNECT  1 (READ  CHAIN)  ANO 


(1 )  S49->1 TO. 7000 

(2)  149— >32  T 0 .3000 

(3)  : i— >2; o.oooo 
U) o.iooo 

(5>S2->49 
(o) :3->4 
(7):4->a 

(s)  :s->t» 

C9)S6->7 

( io  > : 7->a 

ill  ):e-><5  ;o. 9000 

Ci2)  :t->it.;o.  iooo 

(13) S9->10 

(14) :io->n 

Ub):i  1->12 
Clt»):i2->13 

(17):i3->14  (35) 

(101 :14->I5  (36) 

(  19) : 1  a— >49  (37) 

(20) :i6->17  (38 ) 

(21) :17->18  (39) 

(22) :i3->19  (40) 

(23) :i9->20  (41) 

(24)  S20—>21  (42) 

(25)  521— >22  (43) 

(26)  522— >23  (44) 

(27) :23->24  (45) 

(28)  :24“>25  (46) 

(29) :25->26  (47) 

(30 )  :26— >27  (48) 

(31  )  1 27— >28  (49) 

(3??):2»->29  (50) 

(33 )  *  29— >30  (51) 

(34 )  530— >3 1  (52) 


321 WRITE  CHAIN)  TOGETHER. 


:3i->49 

532- >33 

533- >34 

534-  >35 

535- >36 

536- >37 

537- >38 

538- >39 

539- >40 
:40->4i 
:41->42 
542->43 
:  43— >44 
:44->45 
:45~>46 
:4b->47 
1 47— >48 

540- >49 


CHANGE 
MODEL  NAMES 
P1L3RW ’ 

PROMS 

1 

l->2  3;  7.00E— 0 1  3.00E-01 
• 

I->2  3; .6  .4 

prom: 

o 

8— >9  16  T  7.00E-01  3.00E-01 


0— >9  16* .6  .4 
khom: 

CND  OF  CHANGES. 


r 


CHAIN  POPULATION: 20 

QUEUE  1  TYPE : PS 

COMMENTSOl  1  FOR  CACHE  Fjg4.1.2, 
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rate: i 

CLASS  LIST: I  2  lb  32 

WORK  OMNO.  DISTR:200  100  100  100 

UUEUE  2  TYPE  IPS 

COMMENT :LBUS1 


hate:i 

CLASS  LISTI3  33 

WURK  OMNO.  DISTR:iOO  100 

OUEUE  3  TYPE: PS 

comment: 

rate:i 

CLASS  Lisr:«  14  34 

WORK  OMNO.  OISTR:iOO  iOO  100 

OUEUE  4  TYPE  IPS 

comment: 

kate:i 

CLASS  LIST:S  13  16  26  3S  43 

WORK  OMNO.  DISTRI100  100  100  1600  100  1600 

QUEUE  S  TYPE IPS 

COMMENT: 

hate: i 

CLASS  LISTI6  12  17  27  36  42 

WORK  OMNO.  OISTR 1 1 00  100  IOO  100  100  100 

QUEUE  6  TYPE :PS 

comment: 
rate: i 

CLASS  LIST17  9  11  16  20  30  37  39  41 

WORK  OMNO.  DISTR: 100  100  100  100  1600  1600  100  100  1600 

QUEUE  7  TYPE:PS 

comment: 

rate:i 


CLASS  LISTIS  29  36  *  '  '  *  * 

WORK  OMNO.  OISTR: 200  200  200 

QUEUE  a  TYPE IPS 

comment: 

rate:: 

CLASS  LIST: 19  25  44 

WORK  OMNO.  OISTR: 100  100  100 

QUEUE  9  TYPE IPS 

comment: 

rate:! 

CLASS  LIST:20  22  24  45  47 

WORK  DMNO •  DISTR: 100  100  1600  1600  1600 

UUEUE  10  TYPE  IPS 

COMMENT : 

rate:! 

CLASS  L1STI21  46 
WORK  OMNO.  01STR:2Q0  200 
UUEUE  1 1  TYPE  IPS 
COMMENT I 

hate: l 

CLASS  list: 10  31  40 

WORK  OMNO.  OISTR: 1000  1000  1000 

QUEUE  12  TYPE  IPS 

comment: 

HATCH 

CLASS  LIST! 23  46 

WURK  OMNO.  oistk: 10000  10000 

OUEUE  13  type:ps 

comment: 

rate:i 

CLASS  LISTI49 
WURK  OMNO.  DISTR:0 
RS  T*0. 19/1.23  13:20:39 
EVAL 

MUOEL  NAME  I 
P1L3RW 

VERSION  OATE:  MARCH  16.  1979 
NO  ONET  ERRORS  OETCCTEO. 


'  A  A*A  » 
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.01 

0*056 

N  I  - 
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Fig4.1.2.  The  program  is  self  explanatory:  It  has  a  closed  chain, 

13  queues,  49  classes  of  customers.  The  model  has  read  and  write 
operations  with  class  49  connecting  class  1  (read  chain)  and  class 
32 (write  chain)  together.  Class  49  has  R=.7  chance  to  go  to  the  read 
chain  and  (1-R)s.3  chance  to  go  to  the  write  chain.  Class  1  has 
locality  p».9  to  go  to  class  2  and  p=l-.9=.l  chance  to  go  to  class  3. 
Note  that  this  can  be  easily  changed  to  .7  and  then  .6  as  shown  in 
the  CHANGE  part  in  Fig4.1.1  which  makes  sensitivity  analysis  easy 
once  the  model  is  set  up. 

Workload  features  for  each  device  is  set  up  in  Fig4.1.2. 

Consider  Queue  1  (Dll  for  cache):  It  is  a  processor  sharing  device 
which  has  4  classes  of  customers,  namely  classl, 2, 15, and  32.  The 
service  time  for  these  devices  are  200,100,100,  and  100  respectively. 
Rate:  1  is  redundent  in  this  case. 

By  the  same  token,  the  workload  features  can  be  set  up  for  all 
devices.  This  can  be  done  easily  when  referring  to  the  queueing 
network  model  in  Fig3.4.3. 

4.2  Comparision  of  RESQ  Results  to  the  Corresponding  OPERA  Results. 

The  results  of  P1L3  for  R-.7,p*.6  are  shown  in  Fig4.2.1  and 
Fig4.2.2.  Since  the  utilization  rate  is  a  measure  of  how  much  a 
device  is  utilized,  it  should  be  on  the 

device  level  instead  of  the  class  level.  Comparing  the 
utilization  rates  in  Fig4.2.1  vs  the  results  in  chapter  3.4.2,  we  see 


that  they  are  identical  to  the  third  digit.  They  are  listed  here 
again  : 


Q1 

Q2 

Q3 

Q4 

Q5 

Q6 

OPERA 

.056 

.014 

.018 

.181 

.031 

.237 

RESQ 

.056 

.014 

.018 

.181 

.031 

.236 

Q7 

Q8 

Q9 

Q10 

Qll 

Q12 

OPERA 

.034 

.013 

.282 

.020 

.141 

1.0 

RESQ 

.034 

.013 

.  282 

.020 

.141 

1.0 

Throughputs  of  each  device  are  computed  and  printed  out  under 
the  TP  section.  In  interpreting  this  output,  it  is  clear  that  the 
throughput  at  Ql3(the  dummy  device  with  zero  service  time)  should  be 
used  to  represent  the  system's  total  throughput.  The  throughput  can 
be  looked  up  from  the  table  which  gives  : 


2.43E-04  transactions/nanosec.  *>  243  transactions/millisec. 
(exactly  the  same  as  what  we  ahd  from  OPERA). 


Response  times  of  all  devices  are  also  available  under  the  RT 
section.  Since  class  49  is  the  entry  to  the  system,  the  response 
time  can  be  read  off  under  CH1,N49  which  is  8.24E+04,  again  exactly 
the  same  as  the  OPERA  result  from  3.4.2. 


We  have  shown  that  RESQ's  result  confirms  with  OPERA'S  result. 
Since  the  RESQ  code  is  unavailable,  it  is  uncertain  whether  the 
formulae  used  by  RESQ  are  identical  to  OPERA'S  or  OPERA  turns  out  to 
be  a  special  case  to  the  RESQ  approach.  This  is  not  a  critical  issue 
though.  The  important  part  of  the  ball  game  is  that  now  we  have  an 
intuitive  (easy  to  explain  to  the  managements),  hand  calculable (and 
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even  by  inspection  only#  see  chapter  6)  method  to  estimate  the 
performance  statistics  of  the  complex  INFOPLEX  data  base  computer. 
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5  Lam* 3  Results  Using  P1L3  Model  of  INPOPLEX 

Lam79  evaluated  the  performance  statistics  of  P1L3  model.  A 
listing  of  the  P1L3  GPSS  simulation  model  is  presented  in  appendix.  To 
illustratee  the  model  logic,  the  following  is  a  brief  deescription  of 
the  path  followed  by  a  read-through  transaction.  A  read  request  (TXN ) 
is  queued  in  KIQ3  (the  input  message  queue  of  the  storage  level 
controller  at  level  3).  When  KRP3  is  free,  TXN  is  serviced  and  put  in 
K0Q3,  When  LBUS3  is  available,  TXN  is  sent  to  RIQ3  (the  input  message 
queue  of  the  memory  request  processor  at  level  3)  where  it  waits  for 
RRP3,  the  request  processor.  RRP3  then  searches  its  directory  to 
obtain  the  real  address  for  TXN.  TXN  is  put  into  R0Q3  to  be  sent  to  a 
storage  device, say  D31.  When  LBUS3  is  free,  TXN  is  sent  to  DIQ31.  TXN 
waits  in  DIQ31  (the  input  message  queue  for  device  D31)  for  DRP31  to  be 
free  and  also  for  a  slot  in  DYQ31  (the  output  data  queue  for  D31)  to 
hold  the  retrieved  data.  When  both  conditions  are  met,  DRP31  retrieves 
the  data  and  puts  it  in  DYQ31  where  it  waits  for  the  LBUS3  to  be  free 
and  for  there  to  be  a  slot  inKXQ3  (the  input  data  queue  of  the  storage 
level  controller  at  level  3)  to  hold  the  data.  When  both  conditions 
are  met,  the  data  is  sent  to  KXQ3.  Then  the  data  is  put  in  KYQ3 
waiting  for  the  GBUS  and  for  all  the  upper  storage  levels  to  be  free  to 
receive  the  broadcast.  When  these  conditions  are  met,  the  data  is 
broadcasted  to  all  upper  storage  levels.  At  the  highest  storage  level, 
the  data  is  sent  to  the  appropriate  data  cache  controller  which 
forwards  the  data  to  the  CPU.  (Lam79) 
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5 . 1  Lam's  Results  of  P1L3  of  INFOPLEX . 


A  series  of  simulations  was  carried  out  to  obtain  data  points  by 
varying  the  locality  levels.  The  results  of  these  simulations  are 
presented  in  Fig5.1.1.  Throughputs  are  plotted  against  locality 
levels  in  Fig5.1.2.  In  general ,  as  the  locality  level  increases, 
throughput  also  increases.  A  throughput  of  close  to  one  million 
transactions  is  obtainable  at  about  p*.80  locality  level.  However, 
after  the  p«.80  point,  throughput  drops  sharply  as  the  locality  level 
increases.  This  is  caused  by  the  deadlock  phenomenon. 
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Fig5 .2 .1 
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5.2  Comparision  of  Lam's  Results  with  OPERA  Results. 

Since  the  definitions  of  transaction  completion  time  are  different 
between  Lam's  and  the  queueing  network  model  developed  in  Fig3.4.3,  it 
is  necessary  to  modify  the  Fig3.4.3  model  in  order  to  be  comparable  to 
Lam*  s  model . 

By  simplifying  the  write  submodel  to  a  trivial  model,  namely  : 

49  ->  (with  chance  1-R)  32  ->  49,  we  can  easily  obtain  the 
comparable  queueing  network  model.  The  transition  matrix  is  shown  in 
Figure  5.2.1.  Computations  were  done  for  different  locality  levels 
with  70  percent  read  transactions.  The  results  are  shown  in  Fig5.2.2. 

The  throughputs  and  response  times  are  listed  in  the  lower  part  of 
Fig5.2.2  for  both  Lam  and  OPERA.  The  throughput  are  again  plotted  in 
FigS.l.l.  It  is  exciting  to  see  that  the  the  results  are  comparable  to 
within  a  factor  of  2  except  the  cases  where  simulation  ran  into  the 
deadlock  situation.  This  clearly  indicates  that  by  employing  the 
intuitive  and  cost  effective  OPERA  technique,  the  researcher  can  obtain 
a  rough  estimate  for  the  INFOPLEX  model  under  investigation. 

In  the  next  chapter,  we  extend  the  OPERA  model  to  a  general  DSH-11 
model  and  show  that  by  Inspection,  we  can  obtain  the  celling  throughput 
for  an  INFOPLEX  model  provided  that  the  locality  level  is  not  high 
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6  Extension  of  OPERA  to  General  DSH-11  Models. 


We  have  so  far  discussed  OPERA  with  multi- transaction- type, 
multi-class  modeling  technique  and  have  computed  performance  statistics 
for  P1L3  model  for  different  situations.  Simulation  and  RESQ's  results 
provide  us  with  confidence  in  our  analysis. 

An  interesting  question  to  be  answered  is  that  :  Given  a  PqLl 
model  with  R  proportion  of  read  transactions  and  locality  level  p,  what 
is  the  maximum  throughput  for  the  model  ? 

6.1  A  General  Formula  of  System  Throughput  for  DSH-11. 

From  the  experiences  obtained  previously,  it  is  clear  that  if 
the  service  time  of  device  at  L(i+1)  is  bigger  than  L(i)  by  a 
significant  factor, say  10,  then  when  the  system  reaches  steady  state, 
the  lowest  level  device  will  always  be  the  bottleneck  provided  that 
the  locality  reference  p  is  not  high  enough  to  switch  the  bottleneck 
to  another  device. 

From  the  diagonally  structured  matrix,  we  see  that  for  the 
queueing  network  model  used  in  chapter  4,  the  corresponding  OPERA'S 
system  throughput  is  computed  by  the  formula  below  : 

X (o)«  1/{Z  (b)D  (b)  }  -  1/{V  (read  part) S  (b)+V  (write  part)S(b)} 


1/({R  (1-p)  **  (3-1 )  +  w)*S  (b) ) 
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where  S(b)  is  the  service  time  of  the  bottleneck  device. 

This  relation  holds  for  1  level  case.  Therefore ,  the  system's 
throughput  for  PqLl  model  with  (R,p,S(b))  is  given  by  : 

X  (o)  -  1/({R  (1-p)  **  (1-1  )+w}  *S  (b) )  where  w»l-R 

In  the  chapter  5  model  where  write  operation  is  considered  to  be 
complete  once  the  first  level  is  updated  because  of  the  support  of 
the  store-behind  algorithm,  we  have  w»0. 

In  the  chapter  4  case,  as  p  increases,  the  system's  throughput 
asymptotically  approaches  l/{w*S(b)>.  In  the  chapter  5  model  where 
w-0,  the  system's  throughput  is  is  dominated  by  the  L(l)  device  which 
is  the  slowest  one.  However,  as  p  increases,  (1-p) ** (1-1 )  becomes 
very  small  which  means  only  a  very  small  portion  of  the  transactions 
will  be  propagated  to  the  lowest  level.  Host  of  the  transactions 
will  be  handled  on  the  first  level  because  of  the  high  locality.  It 
is  possible  tha  t  the  bottleneck  will  switch  to  Dll  or  other  devices 
according  to  the  specific  design  and  workload  features.  From  the 
DSH-11  design  point,  we  like  to  be  careful  about  this. 

We  restate  our  observation  here  :  For  a  PqLl  model  of  DSH-11, 
when  the  closed  system  reaches  steady  state,  the  system's  throughput 
is  bounded  by  the  bottleneck  device.  If  : 

1.  There  are  sufficient  customers  inside  the  system  to  cause  a 


bottleneck  situation 


.1™. .. 


1100 


1000 


Figure  6.1.1 


OPERA  /  X(o 

(chpater  5)  / 


/suggested  actual 
/  system  throughput 
f  (in  steady  state  ) 


I  .2  .3  .4  -5  .6  .65  .7  .8 

Lam-OPgRA  <  .22  .09  .13  -.0*  -.28  -.54  —96 


legends  B  *  70f5  (proportion  of  READ  transactions) 
X(o)t  System  throughput. 

5(b) s  slowest  device  service  time, 
w  »  1-B 

Data  for  P1L3  model 


S(b)*R*(l-p) 


t(  chapter  5) 


RESQ( chapter  4) 


-1 

S(b)*(wtR*(l-p)I=J) 


.85  .9  .95  '  P 

(locality  level) 


.  :•••//■■  VvivM-:* 


2.  The  lowest  level  device  is  also  the  slowest  device  by  a 


significant  factor. 

3.  Hie  locality  level  p  is  not  high  enough  to  switch  the 
bottleneck. 

4.  The  traffic  of  any  bus  is  not  heavy  enough  to  cause  that  bus 
to  be  bottleneck. 


then  the  system's  throughput  can  be  estimated  by  : 

X(o)«  l/{  (R{(l-p)**(l-l)}  +  w)  *S  (b)  } 

For  the  Chapter  5  model,  we  have  w-0. 


Fig6.1.1  plots  the  throughputs  for  the  chapter  4  model  and  the 
chapter  5  model  as  a  function  of  locality  p.  It  is  clear  that  :  ' 

> 

; 

1.  The  chapter  4  model  asumptotically  approaches  l/{w*S(b)}. 

2.  The  chapter  5  model  is  an  exponential  function  of 

(1-p) ** (1-1)  at  low  locality  and  becomes  concave  at  high  locality  (  p 
>  .8  )  because  the  switch  of  the  bottleneck  (from  D31  to  Dll).  j 
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6.2  Ceiling  Throughput  of  a  DSH-11  Model. 

It  is  worth  noticing  that  the  queueing  network  model  we 
constructed  has  the  nice  property  of  possessing  a  ceiling 
throughput (an  upper  bound)  to  the  system  under  question. This  property 
is  ascribed  to  the  following  relaxations  that  we  set  for  the  model  : 

1.  Overflow  handling  is  ignored.  We  assume  that  no  existing 
block  has  to  be  evicted  in  order  to  accomodate  an  incoming  block. 

2.  Broadcasting  operation  is  ignored . (this  condition  can  be 
included  by  generating  some  comparable  transactions  to  certain 
devices.) 

3.  Infinite  queue  storage  size  is  assumed. 

4.  No  priority  is  assumed. 

5.  Store-behind  operation  is  ignored  in  the  chapter  5  model. 
Write  operation  is  processed  in  "no  time". 

With  these  constraints  relaxed,  it  is  clear  that  the  throughput 
obtained  from  this  kind  of  model  should  serve  as  a  ceiling  throughput 
to  any  refined  model.  For  instance,  the  throughput  from  a  simulation 
model  should  be  smaller  than  the  throughput  from  the  simplified 
queueing  network  model  because  a  well  developed  simulation  model 
would  take  more  constraints  into  consideration,  hence  possesses  a 
tighter  bound  to  the  system. 


obatined  fro®  OPERA  should  serve  as  upper  bounds  to  Lam's  throughputs 


using  simulation  models.  Two  more  evidences  support  this  view: 

1.  Initially  a  system  is  empty,  transactions  will  be  processed 
at  a  faster  speed,  response  time  will  be  faster  and  throughput 
higher.  As  time  goes  by,  response  time  should  slow  down,  throughput 
decrease  •  Their  product  should  be  equal  to  Nbar,  the  average  number 
of  customers  in  the  system.  If  a  system  was  not  simulated  long 
enough  to  get  rid  of  the  initial  conditions,  the  simulated  throughput 
will  be  higher  than  the  actual  throughput  and  on  the  other  hand 
simulated  response  time  be  faster.  This  explains  why  some  of  the 
simulated  throughputs  are  higher  than  the  OPERA'S  results. 

2.  Bottleneck  analysis  emphasizes  the  behavior  of  the 
bottleneck  device.  When  a  bottleneck  situation  occurs,  the  service 
times  at  non- bottlenecks  are  assumed  to  be  zeros  to  obtain  the 
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bottleneck  throughput.  Hence  the  throughput  obtained  from  this  I 

analysis  should  be  higher  than  the  actual  throughput.  Response  time, 
on  the  other  hand,  is  faster  than  the  actual  response  time  because 

all  non-bottleneck  are  like  "super- conductor"  -  not  delaying  any  I 

work  at  bottleneck  at  all. 

< 

Fig6.1.1  depicts  the  proposed  actual  system  throughputs.  If  one 

« 

computes  the  Nbar's  for  Lam's  simulation,  he  will  definitely  find  \ 

} 

that  the  Nbar's  are  always  smaller  than  the  actual  number  of 
customers  in  the  system.  This  is  proved  to  be  true  (see  FigS.l.l). 
Furthermore,  it  should  be  true  that  the  closer  Nbar  is  to  the  actual 
number,  the  better  the  simulation  results  will  be.  We  will 
investigate  further  and  support  this  view  with  evidences (to  appear  in 

* 

technical  report)  The  arguments  made  in  this  chapter  are 
observational  and  intuitive.  It  is  interesting  that  by  using  the 

; 

OPERA  coupled  with  the  multi-class,  mul ti-transaction-type  modeling  ! 

technique,  we  not  only  avoid  the  complex  mathematics  in  the 
stochastic  queueing  network  analysis,  but  also  "see  through"  the 

t. 

complex  DSH-11  model  by  identifying  the  bottleneck.  Conclusion  of  fl 

4 

this  report  is  presented  in  the  next  chapter  where  discussion  of 

. 

future  directions  along  this  line  of  work  is  also  made. 

! 

rt 

* 


-1 

.1 

■i 

i 

i 
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7  Conclusion  and  Future  Directions 


nils  paper  presented  an  easy  to  understand,  cost  effective,  and 
analytically  tractable  solution  which  yields  sufficient  accuracy  for 
performance  questions.  The  success  of  this  solution  method  is  ascribed 
to  the  operational  analysis  framework  and  the  multi-*- transact  ion, 
multi-class  concept.  The  result  computed  from  this  method  is  close  to 
the  results  from  both  the  simulation  approach  used  by  Lam  and  the  RESQ 
approach  which  uses  stochastic  distribution  and  complex  mathematics. 

It  is  clear  that  the  simple  algorithm  we  used  in  this  paper  can  be 
used  as  a  primary  tool  for  the  evaluation  of  an  interested  system.  If 
the  result  turns  out  to  be  interesting,  we  then  construct  programs  for 
either  RESQ  or  GPSS,  etc.,  to  further  confirm  and  extract  the 
performance  statistics  for  INFOPLEX. 

A  lot  of  work  remains  to  be  done  in  this  area.  For  instance,  does 
the  diagonally  structured  transition  matrix  hold  in  general?  If  so, 
why,  if  not,  can  we  modify  our  technique  so  that  the  the  visit  ratios 
can  always  be  read  off  by  inspection  ?  Secondly,  what  if  the  number  of 
customers  inside  the  DSH-11  system  is  not  large  enough  to  cause  a 
bottleneck  situation?  Thirdly,  wouldn't  it  be  more  natural  to  consider 
an  open  system  rather  than  a  closed  system?  If  an  open  system  is  used, 
how  are  we  going  to  validate  our  algorithms  and  results?  Should  we 
simulate  the  same  model  or  build  a  real  system?  Fourthly,  can  a 
concrete  and  formal  approach  be  employed  to  solidify  the  intuitions  and 
arguments  that  we  made  on  chapter  6?  And  although  we  have  obtained  a 
ceiling  throughput,  is  this  upper  bound  close  to  an  optimal  solution  ? 
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Bow  can  we  obtain  a  tighter  bound  based  on  the  work  that  we  have  done 
so  far?  Finally,  is  there  a  standard  approach  to  decomposing  and 
mapping  a  system  into  a  queueing  network  model  ? 

Performance  evaluation  is  an  indispensable  ring  in  the  design  of 
the  INFOPLEX  data  base  computer.  Simulation  is  always  a  useful 
technique  to  employ  but  it  is  uncertain  when  the  system  will  reach 
steady  state.  The  huge  amount  of  CPU  time  required  ,  in  addition  to 
the  model  building  time,  to  obtain  steady  state  performance  statistics 
makes  it  less  attractive  to  the  researcher.  Traditional  queueing 
netwrok  analysis  involves  a  lot  of  stochastic  assumptions  and  complex 
mathematics  which  are  difficult  to  understand  and  to  gain  insights. 
Oftentimes  researchers  devote  a  lot  but  gain  very  little  out  of  it. 

The  operational  analysis  offers  a  good  opportunity  for  modeler  to  make 
intuitive  arguments  and  to  use  the  results  with  more  confidence  and 
understanding.  It  is  possible  to  devise  a  method  of  solution  and  some 
modeling  technique  which  provides  the  modeler  with  enough  flexibility 
and  confidence  to  map  a  system  and  its  workload  features  into  a 
queueing  network  model  and  then  solve  for  an  answer  yielding  sufficient 
accuracy  for  many  performance  questions.  Future  work  in  this  area 
should  be  aimed  toward  this  goal. 
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